home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / August 96 / Re CW9, RTTI, and ODF.8 < prev    next >
Encoding:
Internet Message Format  |  1996-08-13  |  2.7 KB  |  [TEXT/ttxt]
  1. Subject:     Re: CW9, RTTI, and ODF
  2. Sent:        8/12/96 10:20 PM
  3. Received:    8/13/96 8:51 AM
  4. From:        Jim Lloyd, jim@melongem.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. At 12:04 PM 8/12/96, Steve Ussery wrote:
  9. >Kirk Swenson, (kswenson@keypress.com):
  10. >
  11. >>While this isn't really an ODF topic, I've often wondered why there hasn't
  12. >>been a groundswell of support from programmers for an "override" keyword in
  13. >>C++.  If you could write
  14. >>
  15. >>  override void HandleNotification( Environment*, FW_CNotification&);
  16. >>
  17. >>in a derived class declaration, then the compiler could generate an error
  18. >>message if no compatible virtual method were found to override, and many
  19. >>simple errors like this could be avoided.  I suspect most C++ programmers
  20. >>have spent time chasing down this kind of thing at one time or another, and
  21. >>it seems sensible to have the language and compiler provide some
  22. >>assistance.  The tenor of opinion on the C++ standards committee seems to
  23. >>be against adding new keywords to the language, however, and the
  24. >>standardization process is nearing completion, so I'm not holding my
  25. >>breath.
  26. >
  27. >I've never really thought much about this particular problem but I think
  28. >Kirk
  29. >is right.  I can remember making the mistake of thinking I was overriding
  30. >a method in a base class when actually the prototype of the overridding
  31. >method
  32. >did not exactly match the base method.  The end result was that my
  33. >application
  34. >compiled without error but behaved bizarrely.  As I remember, it was a
  35. >very
  36. >difficult bug to find.  (Thank goodness for source-level debuggers!  I was
  37. >at that time stuck with only MacsBug.)  Perhaps this is a defect of C++
  38. >that
  39. >should be addressed by a future standard.  I would see no problem with it
  40. >if it was strictly optional (and therefore broke no existing code.)
  41. >
  42. >My vote, for what's worth, is that you suggest it to the C++ standards
  43. >committee.
  44.  
  45. My 2 cents to this thread:
  46.  
  47. First, Kirk's original guess is correct: the ANSI/ISO committee will not
  48. accept new keywords at this point in the process. If the proposal was
  49. accepted, it would either break almost every single C++ program currently
  50. existing, or it would have to be optional, in which case it serves very
  51. little purpose.
  52.  
  53. However, I don't think there is any need for it. A good compiler can
  54. already issue a diagnostic for this problem. I generally consider
  55. Codewarrior to be pretty good, but in this case it doesn't issue a
  56. diagnostic. For what it's worth, Symantec's compilers will issue a
  57. diagnostic along the lines of "overloaded member function hides override".
  58. I believe Microsoft's compilers also issue a diagnostic.
  59.  
  60. Jim Lloyd
  61.  
  62.  
  63.